# Evergreen v6 Migration Guide

Evergreen v6 is one of the biggest releases of Evergreen yet. We've spent a lot of timing thinking about how to let consumers extend Evergreen,
and as a result have made quite a few changes to how you might use it. Please follow the list of breaking API changes below, and reach out via GitHub Issues if there's anything
that you're seeing that we might have missed!

# No more css prop {#css-prop}

Previously, `<Pane />` and `<Text />` had a `css` prop, which allowed consumers to write arbitrary css styles (including composing pseudoselectors) and pass those
through to the underlying `<Pane />` and `<Text />` components.

With this removed, we encourage either using the standard Evergreen components directly, or taking a CSS-in-JS route to adding those styles (via className for instance).

```diff readonly
 const MyComponent = () => {
-  return <Pane css={ {':hover': { backgroundColor: 'red' }}} />
+  return <Pane className={backgroundRedClass} />
 }
```

# No more hasTrim prop on Alert {#has-trim}

Previously, `<Alert />` had a `hasTrim` boolean prop to control the left border appearance (which was provided by default). Now you can override this directly through props or via theming instead, if you so choose:

```diff readonly
-<Alert hasTrim={false} />
+<Alert border="none" />
```

# No more isSolid prop on Badge or Pill or Avatar {#is-solid}

Previously, `<Badge />`, `<Pill />`, and `<Avatar />` had an `isSolid` boolean prop to control the color appearance (which was `false` by default).

For `<Badge />` and `<Pill />` you can use `appearance="solid"` or `appearance="subtle"` (default) instead. Note that the defaultTheme in v6 does not have a `solid` appearance included, so you'll have to style that yourself via theming if you want it! The classicTheme will include both appearances out of the box.

```diff readonly
-<Badge isSolid />
+<Badge appearance="solid" />
```

For `<Avatar />` you can supplement this behavior through custom theming.

# No more BackButton component {#back-button}

For v6, we decided to remove the `<BackButton />` component as it expanded our surface area without adding a ton of value under the hood.

If you consume `<BackButton />` in your own application, please feel free to re-consume `<BackButton />` and its types as following:

```diff readonly
+import React, { forwardRef, memo } from 'react'
+import { ArrowLeftIcon, Button } from 'evergreen-ui'
+
+const BackButton = memo(
+  forwardRef(function BackButton({ children = 'Back', ...props }, ref) {
+    return (
+      <Button iconBefore={ArrowLeftIcon} {...props} ref={ref}>
+        {children}
+      </Button>
+    )
+  })
+)

+BackButton.propTypes = {
+  /** Composes the Button component as the base. */
+  ...Button.propTypes
+}
+
+export default BackButton
```

# No more marginTop="default" on Paragraph or Heading {#no-more-default-margin-top}

The default theme (and even classic themes) exported by Evergreen no longer support `marginTop="default"` as a "special" property. We recommend defining your own
margin and applying that as standard in your codebase.

```diff readonly
- <Heading marginTop="default"> ... </Heading>
+ <Heading marginTop={majorScale(3)}> ... </Heading>
```

# SegmentedControl has been renamed to Group {#segmented-control}

We're deprecating the `SegmentedControl` in the next major version of Evergreen as we've seen it cause confusion for when to use it instead of other form controls or navigation components.

The internals have been slightly modified to make use of the new low-level `Group` component that implements the [WAI-ARIA Group role](https://www.w3.org/TR/wai-aria-1.1/#group).

This means that each option is represented as `Button`. If you were extracting values from form submission that included this component you may have changes to make.

Additionally, we've unified the sizing API so SegmentedControl also accepts a `size` prop just like Button, TextInput, Group, etc.

# Table.Row switched onKeyPress to onKeyDown {#table-row}

`onKeyPress` is [no longer recommended](https://developer.mozilla.org/en-US/docs/Web/API/Document/keypress_event) and should be subbed out with `onKeyDown`.

Previously, `Table.Row` accepted and bubbled the `onKeyPress` even during `onKeyDown` – this behavior has now been normalized to do the expected thing. If you pass `onKeyPress` it will only be invoked during `onKeyPress` (it's passed down to the container component blindly). This may result in a behavior change if you were previously using `onKeyPress` on table rows.

```diff readonly
- <Table.Row onKeyPress={() => {}} />
+ <Table.Row onKeyDown={() => {}} />
```
